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Motivation 


■  DoD  projects  meet  conditions  that  make  the  Real  Options 
approach  attractive  for  the  valuation  of  flexibility  in  system 
architectures: 

♦  High  uncertainty  due  to  long  anticipated  operational  life  with 
technological  change  and  a  dynamic,  changing  operational 
environment 

♦  Flexible,  modular,  open  architectures  are  a  means  to  mitigate 
against  the  risk  inherent  in  the  uncertainty 


Real  Options  values  the  flexibility 
built  into  a  system  architecture 


Can  help  justify  investment  in  flexibility  up  front  and 
support  analysis  of  alternatives 
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Real  Options 


Traditional  cost  analysis: 

•  Estimate  cashflows 

•  Discount  to  obtain  NPV 

•  Make  a  invest/not  invest  decision 

•  Real  Options  estimate  a  dollar  value  on  the  ability  to 
make  choices  -  decision  flexibility  has  value! 

Black-Scholes  Equation 


C  =SxN(d1)-  Ee-rtN(d2) 
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Real  Options  for  Capabilities 

■  DoD  acquires  systems  to  deliver  capabilities  to 
the  warfighter 

Real  Options  values  the 
flexibility  based  on  a  cost- 
benefit  analysis  assuming  all 
benefits  can  be  put  in  dollar 
terms 


Capabilities  are  not  measured  in  dollars  $$$$$ 

■  The  Real  Options  framework  needs  to  be  adapted 
to  the  way  DoD  values  and  acquires  systems 
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Sea  level  dash  distance  (NMi) 


Value  of  Weapon  Systems  'JS? 


■  Value  is  in  capabilities  delivered  by  system 

■  Options  are  for  additional  future  capabilities 

F-111 
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payload 


endurance 
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Architecture 


Composite  structure 


35 f “  * r>-SfT 


Av/atfon 


LCS  Mission  Modules 


Reserved  space  and  plan 
for  future  accommodation 


The  system  architecture  must  be  designed  to 
accommodate  options 
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Architectural  Options 


The  architectural  options 
approach  involves  the 
following  steps: 

1 .  identify  sources  of 
uncertainty, 

2.  define  measures  for  the 
capabilities, 

3.  model  uncertainty  using 
scenarios, 

4.  partition  the  system 
architecture  into  modules, 

5.  define  architectural 
options  in  the  architecture, 

6.  value  options, 

7.  present  the  valuation  to 
the  decision-maker. 


Capability  Needs  Capability  Needs 

(Today)  (Future) 
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Operational  Uncertainty 


Unknown  operational  needs  during  a  long  lifespan 


B1-B  designed  for  nuclear  mission, 
converted  to  conventional  bombing  mission 


Gerald  R.  Ford  (CVN  78)  anticipated 
operational  life  of  50  years 


Ronald  E.  Giachetti 
May  27,  2014 


Slide  8 


Technological  Uncertainty 

Technological  Evolution 


Sailors  in  submarine 

(source:  undersea  warfare  ) 


Moor  s  Law -2005 
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Architecture  Options 


Architecture 

Uncertainty  Action  Option 

To  Enable  Action 
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Modularization 


Modularization 
Open  interfaces 
infrastructure 


Source:  Jack  Abbot,  AOC  Inc. 
in  presentation  to  NPS  on  April  27,  2006 


Architecture  Heuristic:  Minimize  coupling  between  subsystems 

Maximize  cohesion  within  subsystem 
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Interactions  between  subsystems 


Spatial 

Associations  of  physical  space  and  alignment,  needs  for 
adjacency  or  orientation  between  two  elements 

Energy 

Needs  for  energy  transfer/exchange  between  two  elements  (e.g., 
power  supply) 

Information 

Needs  for  data  or  signal  exchange  between  two  elements 

Material 

Needs  for  material  exchange  between  two  elements 
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Example 


Desert  Patrol  Vehicle 


Ronald  E.  Giachetti 
May  27,  2014 


Architecture  Options: 

•  Engine 

•  Weapon 

•  Fuel 

•  Passengers 

•  Mission  modules 

Cost  to  design: 

Engine  compartment  and  mounts  to 
enable  option  for  changing  engine 

Increase/decrease  fuel  capacity 

Mounts/space/interface  for  various 
weapon  types 

Capacity  to  accept  future  mission 
modules 
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Option  Cost  and  Value 
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Conclusions 


Motivation:  Flexibility  is  being  left  on  the  table  -  rethink  system 
architectures  in  terms  of  “options”  can  help  recapture  and  use  this 
flexibility 

♦  Decision  makers  do  think  about  these  types  of  options,  but  the  informal  approach 
may  miss  options,  is  not  based  on  valuation,  and  human  cognitive  limits  in 
evaluating  multiple  options  concurrently 

■  Almost  all  work  on  options  has  looked  at  options  in  the  PROJECT,  this 
work  examined  options  in  the  system  architecture 

■  Previous  work  values  options  using  cost  information;  this  work  valued 
capabilities  using  MOEs/MOPs 

Model  goes  hand-in-hand  with  evolutionary  acquisition  of  capabilities 
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